home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / ien / ien-99 < prev    next >
Text File  |  1988-12-01  |  9KB  |  208 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7.  
  8.  
  9.  
  10.  
  11.  
  12. INDRA Note 753
  13. IEN 99
  14. May 3rd 1979
  15.  
  16.  
  17.  
  18.  
  19.  
  20.  
  21.  
  22.  
  23.  
  24.  
  25.                      NI FTP: Summary and Assessment
  26.  
  27.                             P. L. Higginson
  28.                              C. J. Bennett
  29.  
  30.  
  31.  
  32.  
  33.  
  34.  
  35.  
  36.  
  37.  
  38.  
  39.                ABSTRACT: This note is a brief summary  of
  40.                the  NI FTP, its design aims, and the ways
  41.                in  which  those  aims  are  achieved.   A
  42.                comparison  of  the NI FTP and the DIN FTP
  43.                proposed for AUTODIN II  is  contained  in
  44.                IEN 100.
  45.  
  46.                                      2
  47.  
  48.  
  49.  
  50. 1.  The NI FTP Protocol
  51.  
  52.      This section is a brief summary of the important features of the NI
  53. FTP protocol.
  54.  
  55.      The NI FTP  was  written  by  a  committee  of  people  from  eight
  56. different  organisations  in the UK who between them used a wide variety
  57. of computer systems and hardware.  Computers  used  by  the  group  were
  58. manufactured,  among  others,  by  DEC,  IBM,  ICL,  GEC, PRIME and CTL.
  59. Drafts were widely circulated and discussed outside  the  design  group.
  60. While  the  initial aim was to produce a protocol for transferring files
  61. across EPSS, "network independence" became an overriding aim.  This  was
  62. because  it  was  realised  that  EPSS  would  shortly  be replaced by a
  63. different,  X25-based  network,  and   because   most   of   the   eight
  64. organisations  had multiple systems or their own local networks, and the
  65. ability to use the FTP in all these areas was desired.  There are  about
  66. 15  implementations in progress, of which 3 have so far exchanged files.
  67. UCL has a TOPS20/TENEX implementation which has transferred files across
  68. the  ARPANET,  and tests have begun on interworking with implementations
  69. in EPSS.  
  70.  
  71.      The NI FTP is a two-party file  transfer  protocol.   The  transfer
  72. occurs  in  two  phases.   In the first, the transfer is defined and the
  73. attributes of the data to be transferred are negotiated.  In the second,
  74. the  data  is  actually  transferred.   Three  levels  of  protocol  are
  75. recognised: level 0, which  covers  the  negotiation  of  file  transfer
  76. parameters;  level  1,  which  handles error and flow control during the
  77. transfer, along with any data or time dependent changes in the file; and
  78. level 2, which is the actual transfer of data.
  79.  
  80.      The negotiation phase is simply structured to  be  an  exchange  of
  81. file attributes between the two sides.  These attributes define a common
  82. definition of the file and the transfer within a "conceptual  filestore"
  83. supported  by the two sides.  During this phase, agreement is reached on
  84. such things as character code, file size, file name and  access  rights,
  85. all  of  which  are  regarded  as  attributes  of  the  file  within the
  86. conceptual file store.  It is up to the two ends to map these attributes
  87. into  locally  acceptable  forms  for  their  actual filestores; if this
  88. cannot be done, the transfer may be rejected.
  89.  
  90.      The currently defined attributes cover a basic set of properties of
  91. sequential  files.   This set can be easily extended, and facilities are
  92. provided to enable implementations to  grow  in  an  upwards  compatible
  93. manner.    Every   attribute  has  a  default  value,  which  allows  an
  94. implementor to construct a transfer facility as simple or as complex  as
  95. desired,  in  the  knowledge  that his facility will be able to interact
  96. easily with more complex ones.  This  is  possible  because  quoting  an
  97. unknown  attribute  or  unacceptable  value for an attribute need not of
  98. itself cause a protocol error.  During the negotiation phase,  the  more
  99. complex  implementation  will reduce its attribute set to one acceptable
  100. to the simpler one.
  101.  
  102.                                      3
  103.  
  104.  
  105.  
  106.      The data transfer phase can treat the data  totally  transparently,
  107. but  does provide a user record structure for text files if desired.  It
  108. allows for data compression as an option, which can significantly reduce
  109. the  amount of data actually transferred.  Even if this is not used, the
  110. protocol overhead can be as low as 1 byte in 64.  For  text  files,  the
  111. existence   of   different   degrees  of  formatting  sophistication  is
  112. recognised by allowing a set of common format effectors to be agreed  in
  113. the negotiation phase.  The data can be in a variety of codes, as agreed
  114. during the negotiation phase, and the particular  code  in  use  can  be
  115. changed  during the transfer phase, thus allowing the protocol to handle
  116. special files such as job output files,  graphics  files  with  embedded
  117. text,  or  symbolic files produced by a compiler for debugging purposes.
  118. Binary files can use byte sizes of  any  arbitrary  size  as  agreed  in
  119. advance.
  120.  
  121.      Error control is provided by the use of  data  checkpoints.   These
  122. are inserted by the sender at suitable points, and may be matched to the
  123. characteristics of the file source or destination storage devices.   The
  124. acknowledgement  of  a data mark implies that the data has been securely
  125. stored by the receiver.  The use of a data window of unacknowledged data
  126. marks  enables  the sender to detect problems at the receiving end which
  127. will cause it to suspend the flow of  data.   On  recovery  (or  in  any
  128. appropriate circumstance), the receiver can ask the sender to resume the
  129. transfer starting from any mark after the last mark acknowledged.   This
  130. facility  also  protects  the  transfer  against loss of data within the
  131. network, and can even be used to resume an  interrupted  transfer  in  a
  132. separate session.
  133.  
  134.      Flow control is provided by allowing the receiver  to  request  the
  135. sender to suspend the flow of data, and to tell it when to resume.  This
  136. is primarily intended to  cover  device  interruptions  (eg  mounting  a
  137. magnetic  tape).   The  use  of  these options is again subject to prior
  138. agreement during the initial negotiation phase, as with  all  the  other
  139. attributes.
  140.  
  141.      The mechanics of  the  data  transfer  is  left  to  the  transport
  142. mechanism.   The  protocol  is defined so as to make minimal assumptions
  143. about the transport service.  These  are:  the  transport  service  will
  144. provide  a synchronised sequential bytestream between the two sides with
  145. an acceptably low rate of error, and that if an unrecoverable error does
  146. occur,  there  exists  some  way for the transport service to notify the
  147. application process.  Recovery  would  then  be  handled  by  the  error
  148. control mechanism described above.
  149.  
  150.  
  151.  
  152.  
  153.                                      4
  154.  
  155.  
  156.  
  157. 2.  Assessment of the NI FTP.
  158.  
  159. The design of the NI FTP was governed by four basic objectives:
  160.  
  161.      (i) The protocol should be independent of the communication medium.
  162.  
  163.      (ii) It should be flexible enough to satisfy a diverse  variety  of
  164.      applications.
  165.  
  166.      (iii) It should be able to interface easily  to  a  wide  range  of
  167.      operating systems.
  168.  
  169.      (iv) It should allow "escape routes" such that special features  of
  170.      a particular operating system can be exploited where necessary.
  171.  
  172. The following features of the  protocol  were  designed  to  meet  these
  173. objectives:
  174.  
  175.      (i) The minimal requirements necessary  from  a  transport  service
  176.      were  identified  and  adhered  to, along with the recognition that
  177.      unrecoverable errors (at transport level) may occur.
  178.  
  179.      (ii) The definition of the file is in terms of  a  conceptual  file
  180.      store.   No  restrictions  were  placed on the mapping of this file
  181.      store  to  the  local  file  store,  either   in   the   attributes
  182.      specification or in the definition of the negotiation process.  The
  183.      inclusion of option sets and relational operators in the  attribute
  184.      specification  allows  extensions  to  be  easily incorporated into
  185.      existing implementations and into the protocol itself.  A number of
  186.      parameters  provide  the  required  "escape routes" for areas where
  187.      operating system dependent peculiarities are anticipated.  
  188.  
  189.      (iii) Complete transparency for naming files and for data  transfer
  190.      is possible.
  191.  
  192.      (iv) The "records" of data transfer used within the protocol enable
  193.      mixing  of  control and data within a single connection.  They need
  194.      have no relation to the record structure (if any) used  within  the
  195.      file, unless the user so desires.  The only restriction is that the
  196.      communication medium should deliver eight  bit  bytes  of  data  in
  197.      sequence.
  198.  
  199.      (v) The formats of control commands and attributes are standardised
  200.      in  a machine-oriented form.  The action of the protocol is defined
  201.      as a single file transfer transaction.  Hence the dominant need for
  202.      flexible  command  formats occurs in the negotiation phase, and the
  203.      level 0 commands are very loosely structured  to  allow  indefinite
  204.      extension.   Only a very small number of commands must be exchanged
  205.      during the data transfer; for this reason, a more  rigid  structure
  206.      was adopted for level 1 commands to ease processing overhead.  
  207.  
  208.